Re: Does the shared lib bug work on any suid program ?
Justin Mason (jmason@iona.ie)
Mon, 6 Nov 1995 15:30:51 +0000
Bernd Lehle said:
>- Choose any suid program, that uses a library call, You know the name
>- example: su calls crypt(3)
>- take the library that contains crypt and delete crypt from it
>- add a crypt function that does exec(sh)
>- rebuild the shared library with the new cypt
>- set the shared library path to Your home
>- su
>Right after the Password was typed in, You should have a root shell...
>This game could be played with any suid program, where You know what routines
>it calls.
Most reasonably sane operating systems will ignore the shared library
search path when executing setuid programs, relying instead on the
builtin default (eg /usr/lib). That takes care of the problem you
mention, and this behaviour is built into the kernel.
All well and good, except when a program is run as root with your
environment; then the above restriction doesn't come into effect.
Usually this happens as a result of being exec'd by a setuid-root
program (see the 8glm "at" hole) or as a result of something more
unusual such as this telnetd thing.
By the way, an addendum to ckd's patch: Adam Shostack mentioned LANG as
another useful env var to propagate, along with TZ, USER, TERM, DISPLAY
and TERMCAP.
--j.